In client-server communications, a client communicates with a server via a public communications network, such as the Internet, or a private communications network, such as an Intranet. With respect to the Internet, a web browser communicates with a web server using the Transmission Control Protocol/Internet Protocol (TCP/IP). For the majority of Internet communications, a web browser communicates with a web server using the generic Hyper-Text Transfer Protocol (HTTP) which is transmitted between the web browser and the web server over the TCP/IP link between the web browser and the web server. Most web browsers also enable clients to access other server resources and services including File Transfer Protocol (FTP), Telnet, Wide-Area Information Servers (WAIS), and the like.
Two important security issues related to client-server communications are privacy and authentication. Privacy involves keeping anyone except the intended recipient from being able to read a communication between a client and a server. Privacy is typically accomplished using cryptography wherein communications are encrypted prior to transmission and decrypted upon receipt. Authentication involves verifying that the entity with whom a client or server is communicating is, in fact, who the client or server thinks the entity is.
One authentication method utilizes digital certificates (referred to hereinafter as "certificates") to authenticate a message. A certificate is a set of data that identifies an entity, and verifies that the specific public encryption and signature keys included within the certificate belong to that entity. A certificate is issued by a Certification Authority (CA) only after the CA has verified that the specified public encryption key belongs to the specified entity. Furthermore, a certificate may be issued for a limited duration. Thus a certificate may have a "not before" and a "not after" time associated with the certificate which define the duration of validity of the certificate.
When a client sends a request to access certain resources via a server, the server may request that the client transmit a certificate to the server for authentication purposes. The server may check to see if the certificate is valid by comparing the server's system time (based on the server's system clock) to the validity duration of the certificate. If the current time at the server does not fall within the validity duration of the certificate, then the certificate is rejected as invalid.
In a distributed processing environment, there exists the possibility of clock discrepancies between any two processors. For example, the current time value on Processor-A is 02:00:00 GMT while on Processor-B it is 02:00:15 GMT. Such discrepancies can cause processing errors when a processor's current time is compared with date/time values within input data such as a certificate. As described above, the fundamental purpose of a certificate is to bind a subject entity with the public-key of a public/private key pair. However, the certificate may also contain two date/time values, a "not before" time and a "not after" time, to denote the period for which the subject entity is authorized to use the key pair. These two date/time values together are known as the "public-key validity period".
In a typical scenario, the certificate owner uses the private key to digitally sign some binary data. The binary data, the digital signature, and the certificate are combined to create a message that any recipient can validate both the contents and source. However, if the recipient's clock does not exactly agree with the issuer's clock the recipient may reject the message due to a certificate as either not yet valid ("now" prior to not before) or expired ("now" after not after).
As an example, assume that the signer signs something at 02:00:01 using the private key whose corresponding public key is certified for use not before 02:00:00. If the recipient's clock is a few minutes slow and it only takes a second to get the signed message, then the recipient will deem the signed message invalid. It is not uncommon for certificates to be issued in a non-overlapping fashion where a certificate is valid until midnight of the last day of the month and its successor valid the first second of the following month. In environments where clocks cannot be centrally synchronized or where availability is important, it is, therefore, prudent to have overlapping certificate validities. However, overlap itself does not guarantee availability. Using the newer certificate as soon as it is valid or using the older certificate until just before it expires can cause certificate validation failures at the destination.
One particular problem with false certificate invalidity may arise in the area of Secure Electronic Transactions (SETs). An example of a SET may be a credit card purchase over the Internet. In almost all such transactions, the cardholder's computer system clock is likely to be off by minutes from the merchant's computer system clock. As a result, a merchant or payment gateway who utilized their signing or encryption certificates up to the very last second of validity would cause many of their customer's transactions to fail. Likewise, if a merchant or payment gateway uses a brand new certificate as soon as it is valid, the same problem may arise.
Thus, a need exists for improvements in the selection of date limited information to overcome the limitations of unsynchronized clocks at different processing systems.